In the electronics industry, multi-billion dollar capital costs for semiconductor fabrication facilities have been a motive force for a trend towards bifurcating design and fabrication. Some organizations assume innovation risk and focus on designing devices while shifting capital risk in outlays for fabrication facilities to other organizations. In a complementary manner, fabrication foundries assume capital risk for a multi-billion dollar facility while shifting innovation risk to design organizations.
While economic factors lead to a bifurcation of design and fabrication, the technical problem remains coupled. That is, the structure of a realized semiconductor device reflects the fabrication processes used to make the device. Accordingly, to ensure accurate realization of a design, best practices are implemented which include information about the fabrication foundry processes in design software tools. The foundry process information is typically in the form of complex models, which are referred to as Process Design Kits (“PDKs”).
From time to time, users revise PDKs because accuracy of the information in a PDK is critical. One piece of incorrect data can potentially cause problems that range from loss of time due to rework to catastrophic failure of fabricated devices. A problem thus arises in how to detect changes due to a PDK revision. Some changes are desired and clear on their faces, however, other changes may be latent, unforeseen or undesired. As a result, continuous and intense efforts are needed to support a PDK infrastructure. Demand for such efforts is affected by factors, such as, the number and extent of PDKs supported by an organization, changes to underlying design software capabilities, changes to fabrication process rules, and requests for additional capabilities from designers.
Heretofore, related art approached the problem of detecting changes due to a PDK revision with reliance on visual inspection of results or brute force techniques, such as, the UNIX diff routine which compares files. Visual inspection is intelligent because it is human-based, but is time consuming and prone to error because humans are not automatons. On the other hand, brute force techniques can be fully automated, yet are not intelligent in that they produce copious irrelevant output (date/time stamps, machine names, insignificant textual or format changes, etc.), which may camouflage pertinent changes.
Hence, it would be desirable to provide an automated and intelligent method to, amongst other things, detect and report changes in a PDK in order to verify revisions prior to re-release and use by designers.